DIY Exercise 9-1: Use validators to validate response schemas
Time estimate: 2 hours
Objectives
In this exercise, you control message flow using validators. You will:
· Validate REST response schemas.
· Validate SOAP response schemas.
· Retrieve data concurrently.
· Filter retrieved data.
Scenario
You are tasked with adding some new functionality to an existing project that involves retrieving data from different sources concurrently. The new requirement is to validate the responses returned from each individual data source and filter the final payload if the payload does meet certain criteria.
Import the starting project
Import /files/module09/route-mod09-starter.jar (in the MUFundamentals4.x DIY Files zip that you can download from the Course Resources) into Anypoint Studio.
Validate the Accounts REST response schema
In the implementation.xml file’s accounts flow, add the JSON module and use the Validate schema operation to validate the REST response returned to the HTTP Request. Use the schema src/main/resources/schema/accountsSchema.json to validate against the REST request.
Validate the Flights SOAP response schema
In the implementation.xml file’s flights flow, add the XML module and use the Validate schema operation to validate the SOAP response from the web service. Use the schema src/main/resources/schema/flightsSchema.xsd to validate against the SOAP request.
Test the validators
Test the validators by making requests to the following URLs:
http://localhost:8081/flights
Change the validation rules so the response fails validation
Edit the accountsSchema.json file and the flightsSchema.xsd file to introduce a validation rule that is not met by the accounts and flights calls. For example, modify the XSD Schema file by changing the key name to something different than what is actually returned by the Delta SOAP service response:
<xs:sequence>
<xs:element name="airlineName-BAD" form="unqualified" type="xs:NCName"/>
For the JSON schema file, change a key name in the required array value:
"required": ["salesID-BAD","id","firstName", …]
After you verify the validation fails for accounts and flights, change the schemas back to the correct schemas.
Concurrently process both requests
In the main.xml file, create a new flow listening on the HTTP endpoint /flights_accounts to concurrently retrieve data from the accounts flow and the flights flow in implementation.xml.
Filter the retrieved data
Add a Choice router to filter out any empty data returned from either the flights flow or the accounts flow. There are three possible empty data scenarios:
· flights is empty
· accounts is empty
· flights and accounts are both empty
Return a message to the client that states that the payload returned from flights, accounts, or both are empty.
Hint: If there are no values returned from the SOAP service, the key listAllFlightsResponse will contain the value null.
Combine data
In the same Choice router, add another branch to return the flights and accounts data as a new JSON data structure to the client if flights and accounts are not empty.
Here is what the new JSON data structure should look like:
{
accounts: {
attributes: { … },
payload: { … }
},
flights: {
attributes: { … },
payload: { … }
}
Verify your solution
Load the solution /files/module09/route-mod09-solution.jar (in the MUFundamentals4.x DIY Files zip that you can download from the Course Resources) and compare your solution.